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Intellectual Property Rights 



IPRs essential or potentially essential to the present document may have been declared to ETSI. The information 
pertaining to these essential IPRs, if any, is publicly available for ETSI members and non-members, and can be found 
in ETSI SR 000 314: "Intellectual Property Rights (IPRs); Essential, or potentially Essential, IPRs notified to ETSI in 
respect of ETSI standards", which is available from the ETSI Secretariat. Latest updates are available on the ETSI Web 
server ( http://webapp.etsi.org/IPR/home.asp) . 

Pursuant to the ETSI IPR Policy, no investigation, including IPR searches, has been carried out by ETSI. No guarantee 
can be given as to the existence of other IPRs not referenced in ETSI SR 000 314 (or the updates on the ETSI Web 
server) which are, or may be, or may become, essential to the present document. 



Foreword 

This Technical Specification (TS) has been produced by Joint Technical Conmiittee (JTC) Broadcast of the European 
Broadcasting Union (EBU), Comite Europeen de Normalisation ELECtrotechnique (CENELEC) and the European 
Telecommunications Standards Institute (ETSI). 

NOTE: The EBU/ETSI JTC Broadcast was established in 1990 to co-ordinate the drafting of standards in the 
specific field of broadcasting and related fields. Since 1995 the JTC Broadcast became a tripartite body 
by including in the Memorandum of Understanding also CENELEC, which is responsible for the 
standardization of radio and television receivers. The EBU is a professional association of broadcasting 
organizations whose work includes the co-ordination of its members' activities in the technical, legal, 
programme-making and programme-exchange domains. The EBU has active members in about 
60 countries in the European broadcasting area; its headquarters is in Geneva. 

European Broadcasting Union 

CH-1218 GRAND SACONNEX (Geneva) 

Switzerland 

Tel: +41 22 717 21 11 

Fax: +4122 717 24 81 



Introduction 

IP Datacast over DVB-H is an end-to-end broadcast system for delivery of any types of digital content and services 
using IP-based mechanisms optimized for devices with limitations on computational resources and battery. An inherent 
part of the IP Datacast system is that it comprises a unidirectional DVB broadcast path that may be combined with a 
bi-directional mobile/cellular interactivity path. IP Datacast is thus a platform that can be used for enabling the 
convergence of services from broadcast/media and telecommunications domains (e.g. mobile/cellular). 
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Scope 



The present document presents guidelines on how to develop terminals and network infrastructure equipment to allow 
seamless handover within one IP platform, in order to continue IP Datacast service consumption. These guidelines rely 
on the DVB-H [1], TR 102 377 [14], and IP Datacast phase 1 [2] specifications. 

Roaming between IP platforms will be addressed in a subsequent version of the present document. 



2 References 

References are either specific (identified by date of publication and/or edition number or version number) or 
non-specific. 

• For a specific reference, subsequent revisions do not apply. 

• Non-specific reference may be made only to a complete document or a part thereof and only in the following 
cases: 

- if it is accepted that it will be possible to use all future changes of the referenced document for the purposes 
of the referring document; 

- for informative references. 

Referenced documents which are not found to be publicly available in the expected location might be found at 
http://docbox.etsi.org/Reference . 

For online referenced documents, information sufficient to identify and locate the source shall be provided. Preferably, 
the primary source of the referenced document should be cited, in order to ensure traceability. Furthermore, the 
reference should, as far as possible, remain valid for the expected life of the document. The reference shall include the 
method of access to the referenced document and the full network address, with the same punctuation and use of upper 
case and lower case letters. 

NOTE: While any hyperlinks included in this clause were valid at the time of publication ETSI cannot guarantee 
their long term validity. 

2.1 Normative references 

The following referenced documents are indispensable for the application of the present document. For dated 
references, only the edition cited applies. For non-specific references, the latest edition of the referenced document 
(including any amendments) applies. 

[1] ETSI EN 302 304: "Digital Video Broadcasting (DVB); Transmission System for Handheld 

Terminals (DVB-H)". 

[2] ETSI TS 102 468: "Digital Video Broadcasting (DVB); IP Datacast over DVB-H: Set of 

Specifications for Phase 1 " . 

[3] ETSI TS 102 472: "Digital Video Broadcasting (DVB); IP Datacast over DVB-H: Content 

Delivery Protocols " . 

[4] ETSI TS 102 471: "Digital Video Broadcasting (DVB); IP Datacast over DVB-H: Electronic 

Service Guide (ESG)". 

[5] Jani Vare, Matti Puputti: "Soft handover in terrestrial broadcast networks". Proceedings of 

MDM2004. 

[6] ETSI TS 102 470: "Digital Video Broadcasting (DVB); IP Datacast over DVB-H: PSI/SI". 

[7] Void. 
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[8] Void. 

[9] Void. 

[10] Void. 

[11] Void. 

[12] ISO/IEC 13818-1: "Generic coding of moving pictures and associated audio information". 

[13] lEC 62002-1 "Mobile and portable DVB-T/H radio access - Part 1: Interface specification". 

2.2 Informative references 

[14] ETSI TR 102 377: "Digital Video Broadcasting (DVB); DVB-H Implementation Guidelines". 

[15] ETSI TR 101 21 1: "Digital Video Broadcasting (DVB); Guidelines on implementation and usage 

of Service Information (SI)". 



3 Definitions and abbreviations 

3.1 Definitions 

For the purposes of the present document, the following terms and definitions apply: 

cell: geographical area that is covered with DVB-T signals delivering one or more particular transport streams 
throughout the area by means of one or more transmitters 

NOTE: The cell may in addition contain repeaters. Two neighbouring cells may be intersecting, or fully 

overlapping. The cell_id that is used to uniquely identify a cell is unique within each original_network_id. 
For hand-over purposes it is more convenient if the transport streams associated with the cell cover 
exactly the same area, or only one transport stream per cell is used. 

DVB Network: collection of MPEG-2 Transport Streams, each carried in a multiplex, and transmitted on a single 
delivery system 

NOTE: DVB network is identified by network_id. 

IP flow: flow of IP datagrams each sharing the same IP source and destination address 

NOTE: An IP flow is identified within an IP platform by its source and destination addresses. IP flows on 

different IP platforms may have the same source/destination addresses, but are considered different IP 
flows. IP flows may be delivered over one or more IP streams. 

IP platform: set of IP flows managed by an organization 

NOTE: The IP platform represents a harmonized IP address space that has no address collisions. An IP platform 
may span several Transport Streams within one or more DVB networks. Several IP platforms may 
co-exist in the same Transport Stream. IP platform is identified by platform_id. 

IP stream: physical mapping of an IP Flow to transport_stream_id, original_network_id, service_id, component_tag, 
and IP source/destination addresses 

NOTE: An IP stream is delivered on an MPE section stream. 

Multiplex: stream of all the digital data carrying one or more services within a single physical channel (characterized 
by parameters like carrier frequency and modulation modes) 

Sub-Cell: geographical area that is part of the cell's coverage area and that is covered with DVB-T signals by means of 
a transposer 

NOTE: In conjunction with the cell_id the cell_id_extension is used to uniquely identify a subcell. 



ETSI 



ETSI TS 102 611 VI .1.1 (2007-10) 



Transport Stream (TS): stream of transport_packets, as defined in ISO/IEC 13818-1 [12] 



3.2 



Abbreviations 



For the purposes of the present document, the following abbreviations apply: 



CBMS 


Convergence of Broadcast and Mobile Services 


DVB 


Digital Video Broadcasting 


DVB-H 


DVB-Handheld [1] 


ESG 


Electronic Service Guide [4] 


IPDC 


IP DataCast 


NW 


NetWork 


TS 


Transport Stream 



Background 



The focus of the present clause is to provide a brief introduction on PSI/SI tables and descriptors used in IPDC in 
DVB-H Systems as well as to describe basic handover concepts. 



4.1 



Overview 



A DVB network is uniquely identified by a network_id. A DVB network consists of one or more Transport Streams 
(TSs), each being transmitted by one or more DVB signals. All emitting sites identified by cell_id's of a network do not 
need to transmit all TSs of the network. Information about a DVB network is available within the NIT sub_table 
(identified by network_id). The NIT lists all TSs and DVB signals available within the DVB network. The NIT is 
carried within each DVB network. 



DVB networks 


DVB network 1 

ID: network id 

PSI/SI: NIT 






^^ 








^^ 


^ 








\^ 


Transport Streams 


Multiplex 1 

ID: transport_strearn_id + 

original network id 

PSI/SI: PAT 




Multiplex 2 

ID: transport_stream_id + 

original network id 

PSI/SI: PAT 




Multiplex 3 

ID: transport_stream_id + 

original network id 

PSI/SI: PAT 








^^ 










^^ 










^^--^ 


DVB services 


DVB service 1 
ID: service id 
PSI/SI: PMT 




DVB service 2 
ID: service id 
PSI/SI: PMT 




DVB service 3 
ID: service id 
PSI/SI: PMT 








^^ 










^^ 










\^ 


Elementary Streams 


Component 1 
ID: componentjag, PID 




Component 2 
ID: componentjag, PID 




Component 3 
ID: componentjag, PID 



Figure 1 : Hierarchy of data streams in DVB-H (1) 

An IP stream is a single data stream delivering an IP flow. An IP flow is a flow of IP datagrams, each sharing the same 
IP source and destination addresses, that represent the data content of a stream. An IP stream represents an instantiation 
of such an IP flow to transport_stream_id, original_network_id, network_id, service_id, component_tag, and 
IP_source / destination addresses. An IP flow belongs to exactly one IP platform. Note that an IP stream may be 
announced by multiple INT sub_tables, possibly making it part of multiple IP platforms. 
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IP platforms 


IP platform 1 

ID: platform id 

PSI/SI: INT 






^^ 


"^^-^ 
















^^-^ 


IP flow 


IP flow 1 
ID: IP address 




IP flow 2 
ID: IP address 




IP flow 3 
ID: IP address 








^^ 


"^^^\ 


















^^--^ 


IP streams 


IP stream 1 

ID: transport_stream_id + 

original network id + 

PID 




IP stream 2 

ID: transport_stream_id + 

original network id + 

PID 




IP stream 3 

ID: transport_stream_id + 

original network id + 

PID 



Figure 2: Hierarchy of data streams in DVB-H (2) 



4.2 Network ID and original network ID 

In DVB, the original_network_id is defined as the network_id of the network where the TS originated. For terrestrial 
DVB the concept of an original network, with an original_network_id, could be interpreted as a sort of abstract 
hypothetical network feeding all real networks (in the sense of network_id) in e.g. a country. The original_network_ids 
are typically allocated by DVB on a per-country basis. For each country, a range of network_ids is allocated by DVB, 
which are all different from the original_network_id. It may happen that the original_network_id is the same as the 
network_id of the actual network. 



4.3 Transport Stream (TS) ID 



From the point of view of the DVB -SI specification a network is simply a 'collection of MPEG-2 Transport Stream (TS) 
multiplexes transmitted on a single delivery system', with no mentioning of requirements for emission in all cells of the 
network. From the point of view of [2] there are therefore no particular rules whether a TS needs to be broadcast in all 
cells of a network. It is perfectly in line with [2] to have e.g. a nationwide network with a number of regional TSs, each 
with unique transport_stream_id and content. 



4.4 Rules of uniqueness 



The cell_id that is used to uniquely identify a cell shall be unique within each original_network_id [2] . This implies that 
two networks (network_ids) within one original_network_id (one country) cannot use the same cell_ids for different 
cells. 

A TS can be uniquely referenced through the path original_network_id/transport_stream_id [3]. In other words, a 
transport stream is unique in the scope of an original_network_id. 

For each country a range of network_ids are allocated by DVB, therefore the network_id is unique in the scope of the 
original_net work_id . 



4.5 Basic handover concept 



The basic mechanism for services access and handover within IPDC over DVB-H is to use the IP address (and the IP 
Platform) for the service, as provided by the ESG, and then via the INT find the global path(s) for the IP address: 
{original_network_id, network_id, transport_stream_id, service_id, component_tag} where the IP stream of the service 
can be found. The NIT, together with cell_id on TPS bits, will provide the link between this global path and 
frequency/cell_id/location of a particular TS. 

There are several reasons why a simplified handover approach, relying e.g. on transport_stream_id and/or service_id 
would not in general work. 
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Considering the variety in interpretations regarding the use and exact meaning of TS/transport_stream_id, one cannot 
e.g. be sure to find the desired IP flow(s) even if the transport_stream_id is the same. The receiver cannot rely only on 
the combination {original_network_id / service_id}. 

In the case the triplet {original_network_id / transport_stream_id / service_id} is identical, handover between 
network_ids would be possible. 

In general, a service_id may contain several component_tags, with one elementary stream on each. Knowing just the 
service_id is not sufficient to find the IP flow. 

The service_id may even be different if the transport_stream_id is different. Finally, some interpretations may use the 
service_id, not to announce a particular IP flow (or set of IP flows), but as a label for 'IPDC services', without any 
guarantee regarding the actual IP flow(s) being carried within the service_id. 

As a matter of fact, the basic mechanism for bootstrapping, service access and handover is very robust against various 
interpretations of terminology and PSI/SI rules. If a receiver uses the basic mechanism and gets: 

the IP address (and IP Platform) of the desired IP flow from the ESG; 

the global path(s), i.e. {original_network_id, network_id, transport_stream_id, service_id, component_tag} of 
the IP address from the INT; 

the cell_id/frequency/location of the desired transport_stream_id from the NIT (NIT actual and NIT other); 

the celljd via TPS bits; 

the PID of the desired elementary stream, carrying the IP stream, from the PAT/PMT on the target TS. 

then service access and handover will work in any case. 



4.6 TPS mobility support 



Details on the TPS data used required for handover support with IP Datacast may be found in TS 102 470 [6] and 
TR 102 377 [14], clause 8.5. 

4.7 Data loss avoidance 

Details on avoiding data loss when performing handovers may be found in TR 102 377 [14], clause 8.5. 



5 Handover use cases 

5.1 Overview of liandover use cases 

In this clause, different handover use cases are listed which may occur due to terminal mobility in a IP Datacast over 
DVB-H broadcast system. The handover use cases are distinguished based on usage of PSI/SI tables and TPS. Each 
handover use case requires the terminal to apply a strategy to maintain, whenever possible, service continuity (i.e. no 
user perceivable interruption of the IPDC service being consumed). 

Table 1 summarizes the mobility use-cases for a terminal acquiring IP flows from a given IP platform. 
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Table 1 : Handover use cases 
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Case 


Original 

Network 

ID change 


Transport 

Stream ID 

change 


Network ID 
change 


Cell / Sub- 
cell ID 
change 


Handover based on 
TPS and NIT 
(see note 1) 


Handover based on 

INT, TPS and NIT 

(see note 1) 


1 








X 


applicable 


Applicable 
(see note 2) 


2 






X 


X 


applicable under 
condition (1) 


applicable under 
conditions (1) 
(see note 3) 


3 




X 




X 


not applicable 


applicable 


4 




X 


X 


X 


not applicable 


applicable under 
conditions (1) 
(see note 3) 


5 


X 


X 


X 


X 


not applicable 


applicable under 
conditions (1) 
(see note 3) 


NOTE 1 : See clause 6 and DVB-H IG TR 1 02 377 [1 4]. 

NOTE 2: INT not necessary. 

NOTE 3: This is possible since the INT shall announce IP flows also on other networks. 



Condition (I): Target NIT is available (by NIT_Other or other means). 
Figure 3 graphically highlights the use-cases of table 1 . 




Figure 3: Handover use cases 1 to 5 

5.2 Detection of alternative service reception parameters 
5.2.1 Use Case 1 : Change of cell or sub-cell ID 

In this scenario, the alternative services reception parameters could be found in the NIT (actual) as follows: 

i) The terminal checks the other_frequency_flag in the terrestrial_delivery_system_descriptor in the NIT of the 
actual network to determine whether other frequencies are in use. In this scenario, this flag will show as true. 

ii) The terminal could acquire information on all other frequencies and their cell (sub cell) ids by decoding the 
cell_frequency_link_descriptor. 
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iii) The terminal could acquire information on the geographical location of such cells and the geographical 
location of the current cell by decoding the cell_list_descriptor. 

Based on this, the terminal could check the availability of the signals of the cells where the terminal is located and 
select the ones with the best quality as candidates to handover to. 



IP Platform 1 



IP 

flows 



Original Network 1 



original_network_id • 1 
transport_stream_id : 1 



mapping 



DVB 
services 



4> 



Transport 
Stream 1 



network id: 1 



cell id 



Network 1 



A 
+ 



-(±> 



^ 



cell id: 2 



Figure 4: Handover scenario 1 

5.2.2 Use Case 2: Change of cell ID and network ID 

In this scenario, the terminal can determine other networks in which the same TS and therefore the same IP flow, is 
available. 

If two TSs have the same TS_id and original_network_id, it means they are identical. The terminal needs to find the TS 
that has the same TS_id and original_network_id from the NIT(other), and the corresponding reception parameters from 
the NIT(other). 

i) The terminal could find the TS that has the same TS_id and original_network_id from the NIT(other). 

ii) The terminal could acquire information on all the frequencies and their cell_id's for this TS from the 
cell_frequency_link_descriptor in NIT(other). 

iii) The terminal could acquire information on the geographical location of such cells and the geographical 
location of the current cell by decoding the cell_list_descriptor from NIT(other). 

Based on this, the terminal could check the frequencies carrying the same TS in the neighbouring cells belonging to 
another network and select the one with the best quality. 
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IP Platform 1 



IP 

flows 



Original Network 1 



original_network_id : 1 
transport_stream_id : 1 



network id: 1 



cell id: 2 



mapping 



DVB 
services 



4> 



Transport 
Stream 1 



I Network 1 ; 

-(^ — <±> 



-^ — ^ 

I Network 2 I 



network id: 2 



cell id: 3 



Network Network 
1 2 



Figure 5: Handover scenario 2 



NIT (actual) 



network id: 1 




transport_stream_id: 1 
original_network_id: I 

terrestrial_delivery_system_de 
scriptor 



cell_list_descriptor 
cell_frequency_link_descriptor 



NIT (other) 



network id: 2 



transport_stream_id: 1 
|Original_network_id: I 



terrestrial_delivery_system_de 
scriptor 



cell_list_descriptor 



cell_frequency_link_descriptor 



INT 



platform_id 



IP/MAC_platform_name_descriptor() 
IP/MAC_platform_prov_name_descriptor() 



target_IP_address _descriptor() 

I P/MAC stream_location_descriptor() 



networkjd: 1 
original_network_id: I 
transport_stream_id: 1 
servicejd 
component_tag 



networkjd: 2 
original_network_id: I 
transport_stream_id: 1 
servicejd 
componentjag 



Figure 6: PSI/SI support for handover scenario 2 
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5.2.3 Use Case 3: Change of cell ID and Transport Stream ID 

In this scenario, the terminal could find the same IP flow in another TS from the INT sub-table (i.e. as part of the same 
IP platform), and corresponding reception parameters in NIT(actual): 

i) The terminal could find out each TS that carries the same IP flow by decoding the IP/MAC 
stream_location_descriptor in the INT sub-table. 

ii) The terminal could acquire information on all the frequencies and their cell_ids for these TSs by decoding the 
cell_frequency_link_descriptor in NIT(actual). 

iii) The terminal could acquire information on the geographical location of such cells and the geographical 
location of the current cell by decoding the cell_list_descriptor from the NIT(actual). 

Based on this, the terminal could check the availability of the signals of the cells accessible where the terminal is 
located and select the ones with the best quality as candidates to handover to. 
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flows 




IP Platform 1 










Original Network 1 








original network id : 1 
transport_stream_id : 1 
















network_id : 2 
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Figure 7: Handover scenario 3 
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5.2.4 



NIT (actual) 



network id 



transport_streann_id: 1 
original_network_id:l 

terrestrial_delivery_systenn_de 
scriptor 



cell_list_descriptor 



cell_frequency_link_descriptor 



transport_streann_id:2 
original_network_id:l 

terrestrial_delivery_systenn_de 
scriptor 



cell_list_descriptor 



cell_frequency_link_descriptor 



INT 



platformjd 



IP/MAC_platfornn_nanne_descriptor() 
IP/MAC_platfornn_prov_nanne_descriptor() 



target_IP_address _descriptor() 



IP/MAC streann_location_descriptor() 



networkjd: 1 
original_network_id: I 
transport_streann_id: 1 
servicejd 
connponent_tag 



networkjd: 1 
original_network_id: I 
transport_streann_id:2 
servicejd 
componentjag 



Figure 8: PSI/SI support for handover scenario 3 

Use Case 4: Change of cell ID and network ID and Transport 
Stream ID 



In this scenario, the terminal can determine other networks in which other TSs carrying the same IP flow are available. 

The terminal could find out that the same IP flow is available on another TS from the INT sub-table. From NIT(other), 
the terminal can get information on other networks carrying other TS's with the same IP flow: 

i) The terminal could find each TS that carries the same IP flow from the IP/MAC streamJocation_descriptor in 
the INT sub-table. 

ii) The terminal could acquire information on all the frequencies and their cell Jd's for these TSs from the 
cell_frequencyJink_descriptor in NIT(other). 

iii) The terminal could acquire information on the geographical location of such cells and the geographical 
location of the current cell by decoding the cellJist_descriptor in NIT(other). 

Based on this, the terminal could check the frequencies carrying the same TS in the neighbouring cells belonging to 
another network and select the one with the best quality. 
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Figure 9: Handover scenario 4 
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Figure 10: PSI/SI support for handover scenario 4 
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5.2.5 Use Case 5: Change of Original Network 

The terminal could find the same IP flow in another TS from the INT sub-table that also carries information for other 
networks where the same IP platform is available. Corresponding reception parameters are to be found in the 
NIT(other): 

i) The terminal could find each TS that carries the same IP flow from the IP/MAC stream_location_descriptor in 
the INT. 

ii) The terminal could acquire information on all the frequencies and their cell_ids for these TSs from the 
cell_frequency_link_descriptor in NIT(other). 

iii) The terminal could acquire information on the geographical location of such cells and the geographical 
location of the current cell by decoding the cell_list_descriptor in NIT(other). 

Based on this, the terminal could check the frequencies carrying the same TS in the neighbouring cells belonging to 
another network and select the one with the best quality. 
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Figure 1 1 : Handover scenario 5 
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Figure 12: PSI/SI support for handover scenario 5 



6 Handover implementation guidelines 

6.1 General procedure 

A handover consists of several high-level steps which are listed below. 
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Figure 13: High-level handover procedure 
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1) Initialization: 



Within the initialization phase, the terminal has to acquire a 'start frequency' used for DVB-H reception. 
This frequency may, for example, be acquired by a signal scan or by provisioning the terminal 
accordingly. 

At least the ESG and possibly additional services have to be received, otherwise the execution of a 
handover does not make sense. 

2) Determine list of candidate signals: 

Within this phase, the terminal has to acquire parameters of possible alternative signals by making use of 
information in the PSI/SI tables. Specifically, the NIT and INT tables have to be analyzed. 

The terminal generates a list of a number of candidate signals suitable for a handover. 

3) Determine possible handover cases: 

Within this phase, the handover case(s) of the candidate signal(s) is (are) determined. 

4) Monitor handover conditions: 

The terminal monitors the signal quality (e.g. signal strength, SNR, error rates, etc.) of the current signal 
and candidate signals 

The terminal generates a list of candidate signals (best to worse) in order to select the best handover 
candidate. 

5) Execute handover: 

Finally, the handover may be executed. 
Afterwards, the terminal continues with step 2. 

6.2 Initialization 

In order to obtain a start frequency, a signal scan may be used, or alternatively, the terminal may be provisioned with a 
certain start frequency. 

The signal scan is a process which can be said to provide the foundation for the service discovery and handover. The 
run of the signal scan is implementation specific. However, due to the fact that NIT other is not mandatory for the 
network, a receiver might want to run the signal scan occasionally in order to be up to date with the new networks 
which might become available, especially if the receiver is moving long distances. 

In the signal scan, the receiver scans signals within the selected frequency range, which may be exhaustive or include 
only a subset of the all possible frequencies. The used frequency offset may also cover all possible bandwidth 
possibilities or it may be determined based on the information of the current location, if available. The steps involved in 
the general signal scan dataflow are described below. 

• Step 1 : The receiver attempts to synchronize to the signal within the given frequency range. 

• Step 2: Prior to the synchronization to the signal completely, receiver may have TPS lock. 

• Step 3: In the case TPS lock is achieved, it is inspected whether the DVB-H indicator within TPS bits indicates 
that the signal carries DVB-H services. If the signal is a DVB-H signal, the receiver attempts to synchronize to 
the signal. Otherwise the procedure continues to step 5. 

• Step 4: In case the synchronization is successful, receiver starts to seek and receive the PSI/SI. 

• Step 5: In case there are no more signals to scan, the procedure is exited. Otherwise the scan is continued from 
the next possible frequency. The list of possible frequencies, which are to be scanned, may be limited based on 
information carried within NIT. 
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6.3 Determine list of candidate signals 

As the next step to prepare a handover, the terminal generates a Hst of neighbouring cells. By using information from 
the SI, it is possible to extract information on the location of the current cell and also of other cells. The necessary 
process for this is discussed in detail in TR 101 21 1 [15] and is similar to DVB-T handovers. 



6.4 



Determine handover case 



On the basis of information in the INT, the terminal is able to find parameters of alternative signals ('"handover 
candidates") from adjacent cells that also carry the currently consumed IP flow(s). For each of these handover 
candidates, the terminal needs to evaluate the handover case to access the new signal. The figure below shows how to 
determine the handover case that is valid for a certain handover candidate. The handover cases are discussed in detail in 
clause 5 of the present document. Based on the information in clause 5, a handover algorithm suitable for the present 
handover case may be chosen. The algorithms themselves are described in clause 6.5. 
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Figure 14: Decision on liandover case 



6.5 



Monitor handover conditions 



A handover may be advantageous if the reception conditions are (or may be assumed to be) better when the terminal 
would change reception to an alternative signal that also carries the IP flow(s) currently being received. The exact 
criteria used for this purpose are up to implementation and no binding algorithms have been specified. 

There are a number of parameters which may be used in the decision process. A number of these parameters are 
outlined in detail below. 

In order to avoid ping-pong effects (meaning the terminal changing between two signals unnecessarily frequently), a 
hysteresis should be used for any criteria. 

There are two separate procedures that must be done during the monitoring phase. 

First, the existing signal quality must be monitored in order to evaluate the quality of the signal on which the current IP 
flow(s) is being consumed. If the current signal-quality is "good enough", handover will not be necessary. 

Second, any viable alternative signals must be evaluated, so that if handover is to take place the "best" alternative signal 
available will be selected. 
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If there is not a "better" alternative signal available, then regardless of the condition of the current signal, handover 
should not be attempted. 

6.5.1 Parameters that may be used in monitoring and evaluating 

For DVB-H receivers, there are many parameters that may be monitored and subsequently used in determining (a) when 
handover should take place and (b) the best alternative signal to handover to. 

These parameters include, but are not limited to, the following: 

1) RSSI (Received Signal Strength Indicator): 

The RSSI gives the full spectrum power available at the antenna, over an entire spectrum range. 

RSSI is a measurement of the received radio signal strength (an energy measurement, not necessarily a 
quality measurement). 

2) DP (Derived Power): 

When the signal is processed by the receiver, there will be signal-conditioning performed on that signal. 
In this signal-conditioning stage, there will be a number of filtering and gain stages applied. 

As a result of applying some or all of these stages, it will be possible to derive a power level for the 
received "wanted signal". 

This derived power level may be known as the Derived Power, and it is a good early indicator of the 
possible quality-of- signal available. 

This indicator does not distinguish between the signal power and the noise power. 

3) SNR (Signal to Noise Ratio): 

The SNR is the ratio of the (wanted) signal power to the noise power that is corrupting it: it compares the 
power level of the desired signal to the power level of noise. 

This indicator will be available after the signal conditioning has completed in the signal-conditioning 
stage. 

This value is a good early indicator of the quality-of-signal available. 

4) BER (Bit Error Rate): 

The Reference BER is defined as: BER = 2 x 10"^ after Viterbi decoding in the receiver. 

This criterion corresponds to the DVB-T standard defined Quasi Error Free (QEF) criteria, causing "less 
than one uncorrected error event per hour" [13]. 

It should be noted that the Reference BER is considered to be an un- suitable criterion in the mobile 
environment due to fast channel variations. 

In mobile cases, the Reference BER criteria may give unstable values which could result in an 
underestimation of DVB-H capabilities. 

5) Packet Error Ratio (PER): 

The PER is measured as the number of non-correctable RS packets that were received, over the total 
number of RS packets received. The rule-of-thumb subjective-failure value, as defined in [13], is 
considered to be 1 x 10""^: 

a) Picture Failure Point (PEP). 

The picture failure point is defined in [13] as the minimum C/N value for more than 1 TS-packet 
error in 10 seconds. 
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b) Subjective Failure Point (SFP) in mobile reception. 

The SFP is defined in [13] as a Packet Error Rate (PER) of 1 x lO'^ after the RS-decoder at the 
demodulator TS-output. 

The SFP corresponds to: "On average, one visible error in the video, during an observation period 
of 20 seconds". 

The observation period [13] for the PER-measurement should be at least 800,000 TS-packets 
(corresponding to roughly 2 mins with 16QAM CR=l/2 GI=l/4 mode). 

6) MFER (MPE-FEC Frame Error Rate) : 

The MFER criterion detects errors after complete demodulation and decoding: i.e. after the Viterbi, 
Reed-Solomon and MPE-FEC steps have been completed. 

MFER is the ratio of the number of non-correctable frames over the number of received frames [13]. A 
minimum of 100 received frames is recommended. A very small change in C/N will result in a large 
change in MFER. 

A threshold value known as MFER5 is considered to be the 'limit of an acceptable quality of image' [13]. 
MFER5 means that 5 % of the total number of received frames had non-correctable errors. 

If a DVB-H signal has degraded to an MFER5 level, then the quality of the service being offered has 
already degraded too much. When detecting signal-degradation, MFERl would be a better threshold 
value to use. 

For a typical DVB-H receiver, a pictorial overview of where each of these measurements can be taken is shown in 
figure 15. 
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Figure 15: Parameters for handover decision 

Each of these parameters has advantages and disadvantages associated with it, and some are more suitable for use than 
others. 
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Table 2: Possible parameters for handover decision making 



Parameter: 


Advantages: 


Disadvantages: 


RSSI 


Can be measured quickly. 

Gives a good early indication of poor 

reception conditions. 

No need to demodulate a transport 

stream to estimate RSSI. 


Supplies an estimate for the energy 

available in the band, not the quality of the 

signal. 

Does not give any indication of bit- or 

byte-errors, and so does not provide 

deterministic QoS metrics. 


DP 


Can be measured quickly. 

Gives a good early indication of poor 

reception conditions. 

No need to demodulate a transport 

stream to estimate DP. 


May not be available on some 

implementations. 

Supplies an estimate of the "wanted" 

energy received: but this estimate does 

not distinguish between the signal power 

and the noise power. 

Does not give any indication of bit- or 

byte-errors, and so does not provide 

deterministic QoS metrics. 


SNR 


Can be measured quickly. 

Gives a good early indication of 

reception conditions. 

Gives a relative signal quality. 

No need to demodulate a transport 

stream to estimate SNR. 


Does not give any indication of bit- or 
byte-errors, and so does not provide 
deterministic QoS metrics. 


BER 


Gives a good indication of current 
signal quality. 


Needs to demodulate a transport-stream. 
Not reliable in once-off measurements. 
Can change very quickly in DVB-H 
environments. 


PER 


Good metric to monitor and use for 

deciding when the signal quality is 

degrading. 

Provides good granularity on 

signal-quality conditions over time. 


Needs to demodulate a transport-stream. 
Needs to be measured over a period of 
time (e.g. 10 s). 


MFER 


May be a good metric to use for 
detecting an urgent need for handover. 
Provides good granularity on signal- 
quality conditions over time. 


Needs to demodulate a transport-stream. 
Needs to be measured over a period of 
time (e.g. 2 min). 

When problems are detected at the MFER 
level, it may be already too late to perform 
seamless handover. 



6.5.2 Monitor existing signal quality 



When monitoring the signal-quaHty of a DVB-H signal, a combination of the SNR, PER and MFER metrics could 
provide good QoS information. 

In order to use the PER and MFER metrics, a pre-requisite is that the IP flow(s) is successfully being consumed over a 
period of time (e.g. at least 10 s for PER; at least 2 mins for MFER). 

Once the IP flow(s) is stable, these metrics can be updated and monitored as time progresses. 

The PER metric can be used to give an indication of a slowly degrading QoS. 

It should be possible to set two threshold values: When the PER reaches the first threshold, this could trigger the 
receiver to start looking for a viable alternative signal, while still providing the service on the existing one (figure 16, 
decision point A). 

If the second threshold value is reached, then handover to the best alternative signal should take effect (figure 16, 
decision point B): note that this handover will only make sense if the "best alternative" signal is both available and 
quantifiably better than the current signal (figure 16, decision points C and D). 

The SNR values can be compared and if there is a sufficient positive differential between the two values, then handover 
should take place (figure 16, decision point D). 
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In addition to using the PER metric with two threshold values, the MFER metric can also be monitored. If the MFER is 
seen to change dramatically, then the signal quality could be considered to be degrading quickly: perhaps too quickly to 
wait for a second trigger value in order to seek handover to a better signal. 

In this case, the receiver should compare the existing SNR value to the SNR value of the "best alternative" signal, and if 
there is a sufficient positive differential between the two values, then handover should take place. 
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Figure 16: Monitor existing signal quality 

6.5.3 Evaluate alternative signal quality 

A pre-condition of this step, is that there is a list of possible alternative- signal candidates available. This pre-condition 
will be satisfied by following step 2 in clause 6.1. 
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It is reasonable to assume that the off-time between bursts will be in the order of 2 s. The off-time may be much longer 
than this (i.e. 4 s or more "Soft handover in terrestrial broadcast networks [5]"), but 2 s is a good rule-of-thumb to use 
for practical DVB-H network deployments. 

Any measurements that need to take place during this evaluation cycle must take place in the off- time between bursts. 

The TPS carriers that are available in each DVB-H symbol carry information about the channel-coding, modulation and 
cell identification. These bits can be used during the quality assessment of the alternative frequencies. 

Evaluation of the alternative signals should be performed in a manner that is as time-efficient as possible. 

There are three possible metrics that could be used for this evaluation process, in a time-efficient manner: RSSI, DP and 
SNR. 

The SNR metric will provide the most useful information, and so it is the value that is recommended to be used if it is 
possible to do so. 

During the burst off-time, the receiver should cycle through the list of frequencies provided, and lock to each one. The 
TPS cell-id bits should be checked (to verify that this signal is indeed from the expected cell), and an SNR value should 
be estimated for each frequency. 

The frequency with the strongest SNR value should be considered the "best alternative" signal. 
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Figure 17: Monitor alternative signal quality 



6.6 



Handover execution 



After handover criteria have been met, the handover actually may be performed. Two algorithms for handover have 
been outlined in clause 5.1. The first one is based on the TPS and NIT and is limited to certain handover situations. This 
algorithm is described in detail in clause 6.6.1. The second algorithm, based on TPS, INT and NIT is suitable in all 
handover cases. It is described in clause 6.6.2. 
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Figure 18: Handover procedure 

In order to reduce the probability for data loss, the terminal should attempt to perform handover directly after a time 
slice was received from the currently consumed service from the current signal (see also TR 102 377 [14]). 



6.6.1 Handover based on TPS and NIT 

This method assumes that handover conditions may exist to avoid INT parsing. This is true in the case of cell/sub cell 
ID and Network ID changes (Network ID change restricted to the condition: target NIT available, as shown in table 1), 
but the transport stream remains the same [14]. 

Pre-conditions: 

1) Signal Scan / Initialization and bootstrap have already taken place. 

At least one good network signal carrying a TS has been identified, and this signal has been locked onto. 
There is relevant PSI/SI signalling available. 



2) 
3) 
4) 



A service is being provided. The service is described by: service_id; transport_stream_id; original_network_id, 
network_id. The IP platform is described by: platform_id. 
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5) At least one signal from a neighbouring cell is carrying exactly the same transport stream the receiver is 
currently consuming. 

Receiver Recommendations: 

1) The receiver must refresh its NIT_actual and NIT_other information every time a new multiplex is entered. 

2) If NIT_other is not available, the receiver may tune to other frequencies during the "off-cycle" of the burst, 
and derive NIT_other information by so -doing. 

NOTE: See clause 5 in TS 102 470 [6] for complete list of mandatory and optional signalling that needs to be 
provided by the network. 

3) TPS bits will always be transmitted on DVB-H networks. 

4) When TPS bits are transmitted, then the "cell_list descriptor" and the "cell_frequency_link descriptor" must be 
available in the NIT. This frequency list must be complete. 

6.6.2 Handover based on INT, TPS and NIT 

The limited handover TPS and NIT method described in clause 6.5.1 shall be replaced by the INT, TPS and NIT 
method when conditions defined in clause 6.5.1 are not met. This method should be used when a terminal sees that the 
original network ID and/or the transport stream ID changes as summarized in table 1 . The method relies on the fact that 
INT tables announce IP flows of the same IP platform on other networks. This method works with the same restricted 
conditions as clause 6.5.1 in the case of cell/sub cell ID and Network ID changes, i.e. INT tables shall announce IP 
flows of the same IP platform on other networks and target NIT is available. 

Pre conditions: 

1) Signal Scan / Initialization and bootstrap have already taken place. 

2) At least one good network signal carrying a TS has been identified, and this signal has been locked onto. 

3) There is relevant PSI/SI signalling available. 

4) A service is being provided. The service is described by: service_id; transport_stream_id; original_network_id, 
network_id. The IP platform is described by: platform_id. 

5) At least one signal from a neighbouring cell is carrying exactly the same IP flow the receiver is currently 
consuming. 

6) INT table announces all IP streams on the actual TS; and it will also announce all relevant IP Streams on 
"neighbouring TSs". 

Receiver Recommendations: 

1) The receiver should refresh its INT information every time a new multiplex is entered. 
Network Recommendations: 

1) It is recommended that the INT is announced by adding a linkage_descriptor with linkage_type OxOB into the 
NIT on the actual TS. The list of announced INTs must be complete. 

2) If the NIT cannot be used for announcing INTs, then the linkage_type OxOC will announce the BAT on the TS. 
The BAT will contain linkage_type OxOB. 

3) If a TS carries no INT (and therefore no IP streams), the NIT on the particular TS should still announce INTs 
on other TSs of the actual network. 

NOTE: See clause 5 in TS 102 470 [6] for complete list of mandatory and optional signalling that needs to be 
provided by the network. 

1) Cell_id is mandatory for each cell where DVB-H services are delivered. The cell_id has to be announced in 
TPS bits as well as in the DVB SI. 
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2) The NIT actual shall announce all multiplexes of the actual delivery system, and it shall contain one or more 
cell_list_descriptors announcing cells and sub-cells of the network. This list of cells and sub-cells shall be 
complete. 

3) To better support handover between networks, the presence of NIT_other for each adjacent network is 
proposed (and recommended). 

4) The receiver can achieve handover only if it knows the requested IP flow is available on another multiplex 
and/or frequency: 

It is very important that a multiplex announces the content of adjacent multiplexes by means of INT 
announcing IP flows on adjacent cells, that all frequencies of each multiplex are announced in the 
NIT_actual, and that the geographical locations of each cell is announced in the NIT_actual. 

5) If the INT does not indicate that a particular IP flow is available on a particular TS, then the receiver may 
assume that it is not available on the TS. 
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